home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / July 96 / Re Part Server.5 < prev    next >
Encoding:
Internet Message Format  |  1996-07-10  |  1.6 KB  |  [TEXT/ttxt]
  1. Subject:     Re: Part Server
  2. Sent:        7/10/96 3:47 AM
  3. Received:    7/10/96 8:45 AM
  4. From:        Serge Froment, sfroment@odyssee.net
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. >AppleEvents are the sanctioned mechanism for interprocess communication on
  9. >the Mac.
  10.  
  11. What about Windows? The OD parts served with this server will be ODF-based
  12. cross-platform.
  13.  
  14. >Alternatively, it should be possible, using a shared data section and
  15. >shared memory (probably allocated out of the system heap), to create a
  16. >shared library that implemented interprocess communication without apple
  17. >events. It's more work, but it might provide better performance.
  18.  
  19. At least until Copland. AppleEvents are supposed to be used to remove
  20. polling in MacOS 8 in order to improve performance. That's what they said
  21. at WWDC.
  22.  
  23. Suppose I go with a background task that communicates with AppleEvents.
  24. What technology do you suggest I use to implement it on the Mac: MacApp,
  25. PowerPlant or my own stuff? Of course, if I use either MacApp or
  26. PowerPlant, this means I write framework-independent code as much as
  27. possible and nest it into on a Windows-based framework for the Window
  28. version.
  29.  
  30. Suppose I go with a shared library, I have another problem: I use
  31. NeoAccess, which has its own memory management. Do you think I will have a
  32. hard time make such stuff work inside a shared library? In particular, if
  33. something ever does a NewHandle or calls system code that does a NewHandle,
  34. where such a handle will be allocated?
  35.  
  36. Thanks,
  37.  
  38. Serge
  39.  
  40.  
  41.